6. Best Practices
6.2.
If you want to reschedule the first instance, you’d send DTSTART and DTEND, RECURRENCE-ID, and UID. (iTIP)
6.3.
Reschedules occur in two different varieties (iTIP), rescheduling where the RECURRENCE-ID is supposed to be changed and when RECURRENCE-ID is not supposed to change.
6.3.1.
Rescheduling of one or more instances where RECURRENCE-ID is not subject to change. In this case, recurrence properties are not sent, so the receiver is expected to keep the current recurrence set and simply reschedule what’s already on the calendar to different dates/times.
6.3.1.1.
Single Instance example: Chair sends out a 5 day recurring meeting that repeats Monday through Friday. Chair later reschedules only Wednesday to a different time. The Wednesday instance should retain it’s original RECURRENCE-ID; this property should not be updated.
6.3.1.2.
Many instance example: Chair sends out a 5 day recurring meeting that repeats Monday through Friday. Chair later reschedules Wednesday and Thursday to a different time. The Wednesday and Thursday instances should retain their original RECURRENCE-ID; this property should not be updated.
6.3.2.
Rescheduling of the entire set, where RECURRENCE-ID is expected to change. In this case, recurrence properties are sent, so that the receiver is expected to replace the existing recurrence set with the incoming set.
6.3.2.1.
Chair sends out a 5 day recurring meeting that repeats Monday through Friday. Chair later reschedules the entire event to follow a different rule pattern; this time weekly for 5 weeks on Monday. All of the instances should be replaced with new instances containing data from the master that was sent, with new RECURRENCE-ID properties generated for each.
6.3.3.
Why not always update RECURRENCE-ID? Since RECURRENCE-ID is our key to find that particular instance, it should not be changed unless the entire set is being replaced. The reason is best explained with an example: Chair sends out a 5 day recurring meeting, Monday thru Friday, from 9am to 10am. Chair later reschedules Wednesday to be from 1pm to 2pm. One of their recipients does not receive the reschedule for Wednesday. Chair reschedules Wednesday again this time from 3pm to 4pm. If the RECURRENCE-ID was changed during the 1-2pm reschedule, then the recipient will not be able process this reschedule or any subsequent reschedules or updates. That RECURRENCE-ID will never match any instances on their calendar.
6.4.
When processing a RANGE that is set to THISANDFUTURE for recurrences, the order in which components have been overridden must be used to define which instances are affected by THISANDFUTURE. For example, say an event has three instances A, B and C. If B is overridden with a component with a RANGE=THISANDFUTURE parameter, then both B and C will be affected by the change. However, if C were subsequently changed, the change to C would not incorporate the changes done in B. Alternatively, if C was overridden first, and then B overridden with THISANDFUTURE, then the changes in B would be incorporated into C. Note that this means that the overridden component for C is effectively not used.